Events - 1.60.0

More and more customer require better detail on Allergen information and because iOrder does not have anything specific functionality that allows for easy display of allergens, we've decided that we can make allergen information way more accessible through our Guest Portal. This way we can easily insert an external information right next to the Menu link in the Menu configuration tab in Events Admin app, making navigation much more intuitive:

Moreover, we've also introduced a safeguard so that user won't be able to display an empty in link in the Guest Portal for neither Menu or Allergen information:

Moreover, this information will now be accessible through the Guest Portal Pre-order screen. If the there is a link input in External Allergen / Dietary info URL and the tick-box below is ticked, then a new link will be visible in the Guest Portal Pre-order screen:

Currently, the values on an invoice is not rounded up, as shown below:

However, because of the percentage multiplier, the calculations were sometimes not fully accurate. Therefore, as part of our ongoing efforts to improve invoices within Events, we've decided to round them up more accurately to the last digit in order to ensure accuracy of invoices created and charged:

This will apply to all new invoices created, however, if an invoice was already created and values need to be rounded up, an informative pop-up is displayed to the user:

The below clarify the conditions for rounding up values on invoice:

• When creating new invoice, the round up calculation is used.

• For existing invoices, when edited, any change in quantity, unit price, VAT rate, price, discount, add / remove items automatically trigger the round up calculation.

• If an invoice is edited and only the item name is changed, then an informative pop-up is displayed to communicate the round up action to the user.

At the moment, an Events Admin user could only create a deposit rule that requires a deposit per person. However, this limits the flexibility Admins have when setting up their booking rules or entire Occasions. Moreover, it doesn't properly reflect the realities of larger events - those might be charged differently.

Because of that, we've decided to give Admins and Hosts more manoeuvrability when it comes to setting up booking rules and editing requirements for already existing bookings. This feature now allows Admin to add a booking rule with deposit required per booking rather than per cover. Example shown below:

This way, the Admin can simplify the deposit requirement for certain occasions or Menus in case a larger group or event is expected, where a deposit per individual would not be appropriate.

However, in order to maximise the flexibility, we've also added functionality that allows Hosts (both Events and Tables) on the ground to actively change the requirement if the conditions of the booking change. Please see the screenshots below:

1. Events:

2. Tables

Moreover, it's vital to mention that to avoid confusion for the Guests as well as the Host, once a deposit has been paid, the Host user will be unable to change the type of the deposit. The slider and drop-down choice will be greyed out and impossible to click:

Finally, there are minor changes in the Booking Portal if the new rule is selected:

• If a flat amount deposit per booking in enabled then only the lead guest is be able to pay the deposit. When you click on directly on any of the attendees the Pay Now button will disappear:

• Similarly, in the attendee view the deposit is not payable, with the view showcased below:

All of those changes to the deposit booking rule are also available through our External API.

At the moment the history page has no functionality beyond filters. In order to bring more value to this tool, we've decided to incorporate additional functions:

• Search Bar

  • Search is based on keywords covering all columns

  • Search supports numerical, alphabetical and symbols

  • If a filter is applied for a column and the user uses the search bar, it shall only search within the filtered out data

• Pagination functionality on the History page that matches the design of pagination used throughout Events

  • By default - 25 rows shall be displayed

  • User can choose between 10,25,50,100 in the drop down list

  • Latest data in history shall be displayed by default

Please see the screenshot below with changes marked in red:

Currently, users can set the same arrival and pre-order dates which causes a problem as pre-order are sent in the morning on the day of the event. Since pre-orders must be prepared received and prepared in advance, we've decided to alter the pre-order logic slightly so that the pre-order date cannot be the same as Arrival Date.

Conditions for pre-order date cannot be the same as arrival date:

• Booking rules with pre-order date set as ‘’0’’ also have the 1-day before rule applied.

• Tables & Events applications cover this change.

For example, if the booking has:

• Booking arrival date: 15th

• Booking Rule: Pre-order required 1 day before

• Pre-Order date is automatically set as: 14th.

• User cannot set 15/07/2023 as pre-order due date either on tables or events application

If the Host user attempts to set the same date for pre-order as arrival date then they will see the following error messages:

As part of our ongoing improvements to the Invoice generation we've now added the status of the invoice onto the generated PDF to help with visibility and accessibility of information:

Outstanding:

Paid:

In order to make emails carry more automated information we've added new dynamic fields relating to the Card Guarantee functionality. The addition of Card Guarantee (Pre-Auth) dynamic fields onto the email templates will allow customers to customise emails according to the desired journey / information they wish to send to guests.

• %GuaranteeCutOffDate% - when Card Guarantee is due by

• %GuaranteeRequirement% - Card Guarantee amount

At the moment, Turn Time for the booking was only easily viewable the in the Tables Host app, as seen below:

As such, we've decided to improve visibility and accessibility of this piece of information in Events Host app by adding 2 additional rows (Turn Time, as well as End Time in order to avoid any arithmetic errors) into the booking information view as shown below:

At the moment in the Day Diary view, the Host can only see whether a pre-order is required for the booking with the yellow fork and knife icon, as visible below:

As part of our effort to make key information more easily available we know allow for the number of preorders completed/preorders required is now displayed for the booking on Day Diary, as showcased below:

Incomplete - shows how many pre-orders have been completed so far out of the whole amount required

Complete - through colour change to green shows completed pre-order out of the whole amount required

Continuing the trend of improving flexibility of our functionality we have now added an option to edit outstanding invoices, so that the user doesn't have to generate one from scratch. We believe that will greatly improve the usability of invoices as a feature, as it will allow to create drafts of invoices and later amendments before they are sent out to the customer.

Conditions for editing invoice:

• Invoices that are ‘Mark as paid’ & ‘Cancelled’ cannot be edited.

• Only ‘outstanding’ invoices can be edited.

• All changes made to an invoice are applied after the user clicks on ‘save’ button.

• Editing an invoice is also tracked in the History log.

Example below:

As shown below, an ‘edit invoice’ is available for all existing invoices:

After clicking on the ‘Edit Invoice’ button, the invoice is reopened and the user can edit fields on the invoice, as showcased:

The following fields shall remain uneditable:

• Invoice Reference

• Invoice Created Date

• Booking date

Once an invoice has been edited, the edited date and time is displayed on top the page, as shown

Functionality of buttons during edits:

'Save' Button:

• In order to store and override the previous data, the user must click on the 'Save' button to confirm his action.

• After clicking on 'Save', the 'grey' background is re-applied to all fields

View Invoice PDF button:

• During editing an invoice - 'View Invoice PDF' button is inactive

• Functionality is activated after user clicks on 'save'

Cancel Invoice button:

• During editing an invoice - 'Cancel Invoice' button is inactive

• Functionality is activated after user clicks on 'save'

• Invoice cannot be edited when invoice is 'cancelled'

Mark as paid checkbox:

• During editing an invoice - 'Mark as paid' check is inactive

• Functionality is activated after user clicks on 'save'

• Invoice cannot be edited when invoice is 'marked as paid'

Past bookings:

• 'Editing' functionality shall be available for bookings in the past (if not marked as paid)

• Anonymized bookings - Editing invoices for anonymized booking should not be possible

Invoice Tab:

• Name, Amount Due, Due date shall be updated with the edited data

Bookings List:

• Invoice Due Date & Invoice Amount shall be updated with the edited data

Invoice Template:

• if invoice template is change during edit: we use the initial template (not the updated one)

• if invoice template is deleted during edit: we use the initial template (the deleted one) as its only when they will create a new template

Tasks are an extremely useful tool for Hosts. However, we've recently realised that it's difficult to determine the booking to which an open task is related to, making Host click through multiple screens to find that information:

To fix that, a link the booking panel has been added on the task’s notification pop-up, as shown

By clicking on ‘View booking’, the booking panel for this notification is automatically opened for the user.

Another part of our improvements for the invoice generation experience we have now introduced a safeguard against accidental marking invoice as paid. Previously when user marked an invoice as paid, there was no option to confirm the action, thus making accidental marking possible. With this new feature when clicking on the ‘mark as paid’ checkbox, a confirmation popup shall be displayed to the user, so that said accidents cannot happen:

This is in line with the changes to invoice generation described above, as with them, the invoice cannot be edited after it has been marked as paid.

Conditions for ‘mark as paid’:

• Remaining payment on the invoice is 0.00

• Once an invoice is marked as paid and validated by the user, the invoice cannot be returned to ‘outstanding’ status.

The functionality of exception dates picker already exists in Occasion configuration. Because, it allows the user to choose specific dates, rather than creating an entire rule, we've decided to extend this functionality to Menus. This way, we can now hide Menus on specific dates within the same Occasion.

Please note however, that the old way of selecting exception days is still available and it's up to the User now to choose one that suits their needs better. Below example of how to set up a Manual Date Exclusion:

In the Schedule Details part of Menu configuration, under Exclusions User can now select "Manual Date Selection":

Once selected, User will see a calendar below, from there a simple click on a given date will add it to exclusion, making it impossible to select in the Guest Portal: